Method and apparatus for synchronizing EPG information between server and client

ABSTRACT

A method and apparatus for synchronizing EPG information between a server and a client in a digital broadcasting network are provided. The server updates synchronization files according to information which is modified after a last synchronization file is created according to the update of the server-side EPG information, creates a synchronization file according to information which is modified after the last synchronization file is created, and transfers a synchronization file to one of the clients, where the synchronization file is created first after the EPG information pieces of the clients are updated among from the synchronization files stored in the clients. Accordingly, the server and the client can be easily synchronized with each other by transferring or receiving only one file, since all synchronization files can include the latest update history by transferring only one synchronization file.

CROSS-REFERENCE TO RELATED PATENT APPLICATION

This application claims the benefit of Korean Patent Application No.10-2005-0081999, filed on Sep. 3, 2005, in the Korean IntellectualProperty Office, the disclosure of which is incorporated herein in itsentirety by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Apparatuses and methods consistent with the present invention relate todata synchronization between a server and a client, and moreparticularly, to synchronizing EPG information between a server and aclient in a digital broadcasting network.

2. Description of the Related Art

With the development of multimedia, the number of broadcasting serviceproviders is increasing. Ever since cable broadcasting service providershave started broadcasting for niche markets where over-the-airbroadcasting is not readily received, not only cable television (TV)service providers providing specialized channels of specific genres withbetter quality, but also satellite cable TV service providers haveentered into the market. The service providers use tens to hundreds ofchannels. Information on the channels has to be provided to create a TVtime table and to notify that the channels exist. A service providerallocates a specific channel as an electronic program guide (EPG)channel to provide the channel information. In this case, TV viewerspassively observe the channel information scrolling on a TV screen. Toavoid this, a method has been needed in which information on TV programis transferred through a network, and the information is stored in aclient system so that the information can be immediately obtained at therequest of a user.

In the case of digital broadcasting, the information is provided alongwith program and system information protocol (PSIP) data to be analyzedin the client system. However, the amount of information obtained inthis way is small. For this reason, the information has to be providedthrough a network to provide larger and better information.

However, the cost to use the network and the amount of data to betransferred become excessive when the EPG information relating to manychannels is processed. Therefore, an effective method of synchronizingEPG information is required.

To provide an effective personal video recorder (PVR) by using the EPGinformation, one to two weeks' amount of EPG information is required.Since programs scheduled to be broadcasted are frequently deleted, andnew programs are frequently added, relevant information has to beupdated in the client system. According to how the information isconfigured, communication between a server and a client is significantlyaffected.

FIG. 1 illustrates a structure of a related art digital broadcastingsystem for synchronizing EPG information.

The system of FIG. 1 is disclosed in the Korean Patent No. 10-0385328.When a server administrator adds, deletes, or updates the EPGinformation, the server cyclically creates a synchronization filewhenever the EPG information is modified. In addition, clients, each ofwhich has different synchronization times with each other, separatelyreceive relevant synchronization files to synchronize the EPGinformation. This will be now described in detail with reference to FIG.1.

When the server administrator modifies data, an update date tracing unit101 writes a modification time into a server database 107 along withinformation on which actions (insert/delete/update) have been carriedout.

FIG. 2 illustrates a modification history table stored in the serverdatabase 107 and a file to be transferred. When a server scheduler 103generates an event to create a synchronization file, an update datacreating unit 105 extracts records corresponding to a predetermined timeperiod from the server database 107 to be stored in a file storing unit109. For example, if an update file is created twice a day at 10:00 and22:00, each synchronization file is configured according to the EPGinformation modified between 22:01 to 09:59 and 10:01 to 21:59.

At the client-side, when it is time to update the EPG information, a PVRscheduler 115 generates an event therefore and requests data from theserver via a downloader unit 113. At the server-side, thesynchronization file is transmitted through a data providing unit 111,and a client system requests a retransmission of requiredsynchronization files included in a synchronization file list. After allrequired synchronization files are received at the client-side, thesynchronization files are stored in the file storing unit 109. Then, adata update unit 119 reads the synchronization files and updates a PVRdatabase 121 according to the content of the synchronization files.

However, in this case, the synchronization files created at theserver-side include all content modified during the time period. As aresult, unnecessary content is also included in the synchronizationfiles. This causes file size to increase, thereby deteriorating filetransfer efficiency.

Whenever the EPG information is modified, its modification historyrelating to the actions (insert/delete/update) is stored in the serverdatabase 107. As a result, when data is updated or deleted, themodification history of previous data still remains. This causes a wasteof resources of the server database 107. Further, data may not beefficiently extracted.

For example, referring to FIG. 2, from 07:10 to 07:13, the serveradministrator deletes an item three times and inserts the item fourtimes. This is the same as in the case when no modification occurs eversince the item is inserted at 07:10. Every modification history isstored in the server database in the order of a time sequence. Also, asynchronization file to be transmitted to the client system includes allthe modification history.

At the client-side, when the client system has not been used for long,or the user just has purchased the client system, every synchronizationfile created before current data is configured is received and itsdatabase is updated according to the modified history recorded in thesynchronization file. Consequently, the same process performed at theserver-side has to be repeated at the client-side, thereby performingunnecessary operations.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus for effectivelysynchronizing EPG information between a server and a client, in which anew modification history is applied to all existing synchronizationfiles whenever the EPG information is updated, and data relating tounnecessary EPG information is deleted from a server database after asynchronization file is created.

According to an aspect of the present invention, there is provided amethod of providing synchronization files to clients so as tosynchronize server-side EPG information with EPG information pieces ofthe clients, the method comprising: (a) updating synchronization files,that are created respectively according to the updates of theserver-side EPG information, according to information which is modifiedafter a last synchronization file is created; (b) creating asynchronization file according to information which is modified afterthe last synchronization file is created; and (c) transferring asynchronization file to one of the clients, where the synchronizationfile is created first after the EPG information of the client is updatedamong from the synchronization files updated in the operation (a) andthe synchronization file created in the operation (b).

In addition, the method may further comprise: writing action typeinformation into an action type field of an item modified in an EPGtable whenever EPG information is updated; and initializing the actiontype field after the synchronization file is created in the operation(b), wherein, in the operation (a), the modified information isrecognized with reference to the action type field.

The present invention also provides a computer-readable medium havingembodied thereon a computer program for executing any one of the methodof providing synchronizing files to clients, where the synchronizationfiles are provided by a server to synchronize server-side EPGinformation with each of client-side EPG information pieces.

According to another aspect of the present invention, there is provideda server apparatus for providing synchronization files to clients so asto synchronize server-side EPG information with EPG information piecesof the clients, the apparatus comprising: a file storing unit whichstores synchronization files created respectively according to theupdates of the server-side EPG information; a scheduler which generatesan event to create a synchronization file according to items that aremodified in an EPG table after the last synchronization file among theprevious synchronization files are created; an update informationsynchronizer which updates all previous synchronization files stored inthe file storing unit according to the modified items when the event isgenerated, creates a synchronization file based on the modified items,and stores the synchronization file to the file storing unit; and a filetransfer unit which transfers a synchronization file to one of theclients, where the synchronization file is created first after the EPGinformation of the client is updated among from the synchronization filestored in the file storing unit.

According to another aspect of the present invention, there is provideda method of synchronizing client-side EPG information with server-sideEPG information in a digital broadcasting network, the methodcomprising: receiving a list of synchronization files created accordingto the update of the server-side EPG information; selecting asynchronization file in the list of the synchronization files, which iscreated first after a latest update time of the client-side EPGinformation, and receiving the synchronization file; and updating theEPG information by using the received synchronization file.

In addition, all of the synchronization files in the list may include amodification history of the server-side EPG information from the time offile creation up to the present.

The present invention also provides a computer-readable medium havingembodied thereon a computer program for executing any one of the methodof synchronizing client-side EPG information with server-side EPGinformation in a digital broadcasting network.

According to an aspect of the present invention, there is provided aclient apparatus for synchronizing client-side EPG information withserver-side EPG information in a digital broadcasting network, theapparatus comprising: a file determining unit which determines a file tobe received which is included in a synchronization file list, where thefile is a synchronization file created first after client-side EPGinformation is updated to the latest version; a file requesting unitwhich requests a synchronization file selected in the file determiningunit to a sever; and an update unit which updates the client-side EPGinformation by using a synchronization file received in response to thefile request.

In addition, the synchronization files in the list may reflect therecent EPG information of the server-side.

In addition, the synchronization files in the list may be created suchthat each file name thereof includes information on a file creation dateand time.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features and advantages of the present inventionwill become more apparent by describing in detail exemplary embodimentsthereof with reference to the attached drawings in which:

FIG. 1 illustrates a structure of a conventional digital broadcastingsystem for synchronizing EPG information;

FIG. 2 illustrates the content of a synchronization file forsynchronizing EPG information according to the prior art;

FIG. 3 is a flowchart illustrating a process of creating a server-sidesynchronization file according to an exemplary embodiment of the presentinvention;

FIGS. 4A to 4B illustrate EPG tables according to an exemplaryembodiment of the present invention;

FIGS. 5A and 5B illustrate source codes of synchronization files writtenin the xml format according to an exemplary embodiment of the presentinvention;

FIG. 6 illustrates a structure of a digital broadcasting systemaccording to an exemplary embodiment of the present invention;

FIG. 7 illustrates a structure of an update information synchronizeraccording to an exemplary embodiment of the present invention;

FIG. 8 is a flowchart of a process of a first synchronizer according toan exemplary embodiment of the present invention;

FIG. 9 is a flowchart of a process of a second synchronizer according toan exemplary embodiment of the present invention;

FIGS. 10A to 10B are flowcharts of a process of creating asynchronization file in a server according to an exemplary embodiment ofthe present invention;

FIG. 11 illustrates a process of creating a synchronization fileaccording to an exemplary embodiment of the present invention;

FIG. 12 illustrates a process of creating a synchronization fileaccording to another exemplary embodiment of the present invention;

FIG. 13 is a flowchart of a process of a synchronization file manageraccording to an exemplary embodiment of the present invention;

FIG. 14 illustrates a structure of a client according to an exemplaryembodiment of the present invention; and

FIG. 15 is a flowchart of a process of a synchronization file manageraccording to another exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Hereinafter, the present invention will be described in detail byexplaining exemplary embodiments of the invention with reference to theattached drawings.

FIG. 3 is a flowchart illustrating a process of creating a server-sidesynchronization file according to an exemplary embodiment of the presentinvention.

The synchronization file stores modification history of server-side EPGin order to update client-side EPG information. The synchronization fileis cyclically created and includes the latest update history. Thecontent of the synchronization file may be written in extensible markuplanguage (XML) format as shown in FIG. 5. According to an updatehistory, programs may be written using <Ins>, <Upd>, and <Del> tags.FIGS. 5A and 5B will be described in detail later.

When a server administrator updates EPG information (operation 310), aserver writes action type information (i.e., insert, delete, update,etc.) to an EPG table (operation 320). When a sever scheduler generatesan event to generate a synchronization file, information is extracted onitems which have been actually modified thereafter.

Next, it is determined whether a previously created synchronization fileexists in a file storing unit for storing the synchronization file. Ifit does not exist, an initial synchronization file is created so that itincludes all items contained in a current EPG table, and the initialsynchronization file is then stored in the file storing unit (operation350). If it exists, previous synchronization files are updated accordingto the modified items (operation 360). Thereafter, a lastsynchronization file is created so that it includes only the modifieditems (operation 370). Thereafter, items deleted by the serveradministrator, that is, items of which action type is DEL, are deletedfrom a database.

Accordingly, all clients can obtain the latest EPG information bydownloading only the next subsequent version of a currentsynchronization file regardless of the latest EPG update time of theclients, and the server no longer has to store data relating to deleteditems.

FIGS. 4A to 4B illustrate EPG tables according to an exemplaryembodiment of the present invention.

In the EPG table of FIG. 4A, item 5 is inserted in the case whenprograms corresponding to items 1 to 4 already exist. When a userinserts, deletes, or updates data, it is written in the action typefield. In the action field, unmodified items stay in an initial state ofNULL. After the synchronization file is created, the action file isreinitialized to NULL. Thus, if the action type field is not NULL, itshows that modification has occurred at least once. In the EPG table ofFIG. 4B, the synchronization file is created according to a modificationhistory, and then all of the action type fields are initialized to NULL.

Since the action type field is initialized after the synchronizationfile is created according to the modification history, when items areupdated at a later time, it is possible to determine which items havebeen updated.

FIGS. 5A and B illustrate source codes of synchronization files writtenin the xml format according to an exemplary embodiment of the presentinvention. In FIG. 5A, items 1, 4, 6, 9, and 10 are inserted. In FIG.SB, items 6, 9, and 10 are inserted, item 1 is updated, and items 2 and4 are deleted. For convenience, the synchronization files include onlyan ID of an item in this exemplary embodiment, but all information onthe item may be included in the synchronization file in practice.

The synchronization file of FIG. 5A is the initial synchronization filewhich is the oldest synchronization file. The oldest synchronizationfile is transferred to a client along with other synchronization files.Further, the oldest synchronization file may be used to create referenceinformation which is needed to apply the modification history to othersynchronization files.

Later version synchronization files are created according to only theitems which have been updated with respect to the initialsynchronization file. Thus, when the EPG table is modified andsynchronization files are then updated, the initial synchronization fileis first updated according to the current EPG information. Then, thelater version synchronization files are updated according to only themodification history applied to the initial synchronization file, sothat all synchronization files can include the current EPG information.In the case of a newly purchased client system, or in the case when nosynchronization files are stored in a client database, the latest EPGinformation can be obtained by just downloading the initialsynchronization file. Referring to FIG. 5A, the initial synchronizationfile has only <Ins> tags.

FIG. 6 illustrates a structure of a digital broadcasting systemaccording to an exemplary embodiment of the present invention.

Referring to FIG. 6, a server 607 includes a server scheduler 601, anupdate information synchronizer 602, an update history setting unit 603,a server database 606, a file transfer unit 605, a synchronization filemanager 604 and a file storing unit 620. A client 614 includes a clientscheduler 609, a file requesting unit 610, a file determining unit 611,an update unit 613, and a client database 612.

The server scheduler 601 generates an event to notify the need to createa synchronization file for items in the EPG table, the items which havebeen modified since the latest synchronization file was created.

In response to the event, the update information synchronizer 602extracts items which have been modified during a predetermined timeperiod from the EPG table, updates all previous synchronization filesstored in a file storing unit 620, creates the latest synchronizationfile updated according to only the modified items, and stores the latestsynchronization file into the file storing unit 620.

When the server administrator updates server-side EPG information, theupdate history setting unit 603 writes action type information of eachitem into the EPG table to be stored in the server database 606.Further, the update history setting unit 603 initializes action typefields of the EPG table to NULL when the update information synchronizer602 creates the latest synchronization file. Action type fields showwhich items have been updated after a new time period starts, and theupdate information synchronizer 602 recognizes modified items accordingto the action type field values.

In response to the request of the client 614, the file transfer unit 605transfers a synchronization file list or a synchronization file, and theserver database 606 stores the EPG information.

The synchronization file manager 604 deletes old synchronization filesfrom the server database 606. However, since the initial synchronizationfile has to exist all the time, the content of the initialsynchronization file has to be copied to a second oldest file stored inthe file storing unit 620 prior to the deletion the initialsynchronization file. This will be described in detail later.

When it is time for the client 614 to update the EPG information, theclient scheduler 609 generates an event. Then, the file requesting unit610 requests the synchronization file list from the server 607 bysending a request to the server 607. The file determining unit 611determines the synchronization file to be received which is included inthe synchronization file list, where the synchronization file is asynchronization file created first after the client-side EPG informationhas been updated to the latest version. Then, the file requesting unit610 requests the server 607 to transfer the synchronization filedetermined by the file determining unit 611.

The update unit 613 updates the client-side EPG information according tothe received synchronization file. The client database 612 stores theupdated EPG information. The client scheduler 609 generates an event todownload the synchronization file for synchronizing the EPG information.

As described above, the client 614 can synchronize its EPG informationwith the EPG information of the server 607 by downloading a nextsubsequent version of a current synchronization file. Thus, whenrequesting the synchronization file that is the next subsequent version,the client 614 has to know not only the version of the synchronizationfile currently stored in the client 614 but also the version of thesynchronization file stored in the server 607. Also, the server 607 hasto know the version of the synchronization file stored in the server607. For this reason, when the server 607 generates the synchronizationfile, the data and time of file creation may be included in a file name.

FIG. 7 illustrates a structure of an update information synchronizeraccording to an exemplary embodiment of the present invention.

Referring to FIG. 7, an update information synchronizer 710 includes afirst synchronizer 711, an extractor 712, and a second synchronizer 713.The extractor 712 extracts modified items from a server database 706according to the action type field value as described above. The firstsynchronizer 711 updates an initial synchronization file by using theextracted items. Not all of the items extracted by the extractor 712 areused in updating the initial synchronization file, in practice. Thiswill be described in detail later with reference to FIGS. 8 and 12. Thesecond synchronizer 713 updates the rest of the synchronized filesaccording to items which are used in updating the initialsynchronization file, in practice.

FIG. 8 is a flowchart of a process of the first synchronizer 711according to an exemplary embodiment of the present invention.

When items modified by the extractor 712 are extracted, the firstsynchronizer 711 refers to the action type fields of each item(operation 801) and determines whether a field value thereof is UPD(operation 802). If it is UPD, whether an ID exists within the <Ins> or<Upd> tags in the initial synchronization file (operation 805) ischecked. If it exists, the content of the file is updated (operation807). If it does not exist, the action type fields of the extracteditems are modified to INS (operation 808) to be inserted within the<Ins> tag in the initial synchronization file (operation 811). Forexample, if one item is inserted when the synchronization file iscreated and then the synchronization file is updated, the action typefield of the item extracted by the extractor 712 indicates UPD. However,the initial synchronization file created according to only its previousversion synchronization file does not even recognize that the item hasbeen inserted. Thus, the initial synchronization file recognizes this asINS instead of UPD.

If the action type field indicates DEL (operation 803), whether the IDexists in the <Ins> or <Upd> tags of the initial synchronization file(operation 806) is checked. If it exists, the ID is deleted (operation810). If it does not exist, the content of the item is deleted from theextracted items (operation 809).

If the action type field indicates INS (operation 804), the content ofthe ID is inserted within the <Ins> tag of the initial synchronizationfile (operation 811). In order to create reference information to beused to update the rest of the synchronization files, the extracteditems are modified at the same time the initial synchronization file isupdated. Hereinafter, the reference information will be referred to asupdate reference information.

If the initial synchronization file does not exist when theaforementioned operations are performed, the content of the initialsynchronization file may be referred to. Alternatively, every operationfor modifying the initial synchronization file may be treated as anerror or be cancelled.

FIG. 9 is a flowchart of a process of the second synchronizer 713according to an exemplary embodiment of the present invention.

As described above, the second synchronizer 713 updates the rest of thesynchronization files instead of the initial synchronization file.

74 When the first synchronizer 711 creates the update referenceinformation, the action type field of the update reference informationis referred to (operation 901). Thereafter, if the action type fieldvalue is UPD (operation 902), whether an ID exists within the <Ins> or<Upd> tags in a file to be transferred (operation 905) is checked. Ifthe ID exists, the content of the ID is updated (operation 907). If theID does not exist, the ID is inserted within the <Upd> tag of thesynchronization file (operation 908).

If the action type field value is DEL (operation 903), whether the IDexists in the <Ins> or <Upd> tags of the synchronization file (operation906) is checked. If the ID exists, the ID is deleted (operation 910). Ifthe ID does not exist, the ID is inserted within the <Del> tag of thefile to be transferred (operation 909).

FIGS. 10A to B are flowcharts of a process of creating thesynchronization file in the server according to an exemplary embodimentof the present invention.

When the EPG information is updated in the server (operation 1001), thecurrent action type is written on the action type field of the EPG tableto be stored in the database.

When it is time to create the synchronization file and thus the serverscheduler generates an event therefore (operation 1003), the updateinformation synchronizer updates the synchronization files according tothe modification history of the EPG table. For this, the action typefield of the EPG table is first referred to from the database to extractitems which are not NULL (operation 1004). Next, it is determinedwhether the synchronization file exists (operation 1005). If it exists,the update reference information is created at the same time the initialsynchronization file is updated as described above (operation 1007). Ifit does not exist, the initial synchronization file is created so thatall items of the current EPG table are inserted into the initialsynchronization file (operation 1013). Thereafter, the rest of thesynchronization files are all updated (operations 1008 to 1012). If thelast modification history is applied to all of the synchronizationfiles, and the synchronization file configured according to only thelast modification history is created (operation 1013), the items ofwhich the action field value in the EPG table is DEL are completelydeleted from the database, and all of the action type field values ofthe EPG table are initialized to NULL.

FIG. 11 illustrates a process of creating a synchronization fileaccording to an exemplary embodiment of the present invention.

The server administrator inputs data to update EPG information(operation S10). Then, according to the input data, the update historysetting unit writes action type information of each item to action typefields of an EPG table. FIG. 11 shows an EPG table 1130 with fields forID, Action, Channel Number (“ChNum”), Start Time (“S TIME”), End Time(“E TIME”) and TITLE. There are no inserted items in the first EPG table1130. At a later time, four items are inserted in an EPG table 1140 toreflect the four items in the EPG 1145. In this case, four items aremodified, and the action type thereof is INS.

When the scheduler generates an event to create the synchronization file(operation S40), the update information synchronizer extracts themodified items according to the action type field of the EPG table(operation S50). In order to create the update reference information,the update information synchronizer loads the initial synchronizationfile to a memory (operation S60). Since the initial synchronization filedoes not exist in this time, an initial synchronization file 1100 iscreated in which four items are inserted (operation S70). Up to now,update reference information 1110 is the same to the items extracted inoperation S50. When the synchronization file is created, the updateinformation synchronizer initializes all of the action type fields of anEPG table 1150 to NULL (operations S90).

FIG. 12 illustrates a process of creating a synchronization fileaccording to another exemplary embodiment of the present invention.

The process of creating the synchronization file will be now described.An EPG table 1240 contains five items to reflect the five items on theEPG 1245. In addition, an initial synchronization file 1220 and asynchronization file 1260 exist. In this case, items of ID 2 and ID 3are all replaced by ID 6, ID 5 is replaced by ID7, ID 1 is updated, andID 8 is inserted and then deleted. In other words, the programmingreferred to as ID 2, which was listed to run between 10:00 and 11:00,and ID 3, which was listed to run between 11:00 and 12:00, are replacedby ID 6, which is listed to run between 10:00 and 12:00, as shown in theEPG 1245. Furthermore, the programming referred to as ID 5, which islisted to run between 13:00 and 14:00, is replaced by ID 7 which runsbetween 13:00 and 15:00, as shown in the EPG 1245.

First, the server administrator modifies EPG information in the same wayas described above. As a result, each item of an EPG table 1250 ismodified. Update reference information 1210 is extracted to be appliedto the initial synchronization file 1220, thereby creating an updatedinitial synchronization file 1230. Newly inserted ID 6 and ID 7 areinserted within the <Ins> tag of the initial synchronization file 1220.Since ID 1 already exists within the <Ins> tag, the updated content isoverwritten. When deleting, ID 2, 3, and 5 are deleted since they existwithin the <Ins> tag, but ID 8 is not deleted since it does not existwithin any tags. Therefore, the content of ID 8 is deleted from theextracted items to generate update reference information 1203.

The previous synchronization files are updated according to the createdupdate reference information 1203. Referring to FIG. 12, asynchronization file 1270 is updated by using the previoussynchronization file 1260. That is, ID 5 is deleted from the <Ins> tag,and the rest of items are inserted within relevant tags. After the firstsynchronization file and the previous synchronization file are updated,a last synchronization file 1290 is created which contains only theupdate reference information. As described above, each synchronizationfile may include a file creation date and time so as to know the orderof file creation.

When file creation and update are completed with respect to thesynchronization files, data corresponding to items of which the actiontype field values are DEL is deleted from the EPG table 1250, and theaction type fields are initialized to NULL (operation 1280).

FIG. 13 is a flowchart of a process of the synchronization file manager604 according to an exemplary embodiment of the present invention.

As time elapses, old synchronization files need to be deleted startingfrom the oldest synchronization file, since the content of the old filesbecome the same with each other over time. For example, if a valid timeperiod of EPG information is set to one week, synchronization fileswhich have been created more than one week ago are deleted. In thiscase, as describe above, the initial synchronization file has to existall the time due to the characteristics of the synchronization system ofthe present invention. Thus, a later version synchronization file needsto be configured to be the new initial synchronization file prior thedeletion of the initial synchronization file. The later versionsynchronization file is the second oldest file, following the firstsynchronized file. Hereinafter, the later version synchronization filewill be referred to as a preliminary synchronization file.

When the scheduler generates an event to delete the initialsynchronization file after a predetermined time elapses (operation1310), the initial synchronization file and the preliminarysynchronization file are loaded in a memory (operation 1320). Next, thecontent written within the <Upd> and <Del> tags in the preliminarysynchronization file is all deleted (operation 1330). Thereafter, thecontent of the <Ins> tag of the initial synchronization file and thepreliminary synchronization file are compared with each other, and IDswhich exist only in the initial synchronization file are inserted withinthe <Ins> tag of the preliminary synchronization file (operation 1340).Thereby, the preliminary synchronization file has content indicatingthat all of the items included in the current EPG information have to beinserted. Thereafter, the initial synchronization file is deleted, andthe file name of the modified preliminary synchronization file isdetermined to be the same as the initial synchronization file (operation1350).

FIG. 14 illustrates a structure of a client 1414 according to anexemplary embodiment of the present invention.

Referring to FIG. 14, the client 1414 includes a client scheduler 1409,a file requesting unit 1410, a file determining unit 1411, a database(DB) 1412, and an update unit 1413.

The client scheduler 1409 generates an event to update the EPGinformation after a predetermined time elapses. The file determiningunit 1411 determines a synchronization file to be received which isincluded in the list of synchronization files received from the server607 through the file requesting unit 1410. For this, a system updatetime has to be stored in the client 1414 whenever the EPS information isupdated in the DB 1412. When the synchronization file to be received isdetermined at a later time, the system update time is referred to sothat the synchronization file to be received can be determined to be afile created right after the system update time among from theserver-side synchronization files. This is because the file contains allcontent updated from when the client 1414 updates the EPG information upto the present. As described above, when the server-side synchronizationfile is created, the synchronization file name includes the filecreation date and time. The synchronization file name may be“Update.20050531.10.epg”, which indicates that the synchronization filewas created at 2005, May, 31, 10:00 am. The file determining unit 1411can select a required synchronization file according to the file name.

The file requesting unit 1410 requests the server 607 to transfer thesynchronization file selected by the file determining unit 1411. Inresponse to the request, the update unit 1413 updates the EPGinformation stored in the DB 1412 by using the received synchronizationfile.

FIG. 15 is a flowchart of a process of the synchronization file manager604 according to another exemplary embodiment of the present invention.

The client scheduler 1409 generates an event to update the EPG(operation 1510). Then, the synchronization file list is requested fromand received from the server 607 (operation 1520). To determine thesynchronization file to be received in the synchronization file list, alast update time stored in the DB 1412 is referred to (operation 1530).The synchronization file created first after the last EPG update timehas elapsed, is selected (operation 1540). When the synchronization fileis selected, the file creation date and time included in the file nameare referred to.

Accordingly, in a digital broadcasting network of the present invention,in the server aspect, a storage space can be saved since unnecessarydata is not stored after EPG information is updated. In the networkaspect, network resources required to transfer a synchronization filecan be saved since the file size is reduced according to only a lastupdate state of the EPG information without having to include all updatehistory when the synchronization file is created in a server. In theclient aspect, client-side EPG information can be easily synchronizedwith sever-side EPG information by downloading only one synchronizationfile created first after the currently stored last synchronization filewas created regardless of when the latest EPG information was updated.

Meanwhile, the exemplary embodiments of the present invention can bewritten as computer programs and can be implemented in general-usedigital computers that execute the programs using a computer readablerecording medium. Examples of the computer readable recording mediuminclude magnetic storage media (e.g., ROM, floppy disks, hard disks,etc.), optical recording media (e.g., CD-ROMs, or DVDs), and storagemedia such as carrier waves (e.g., transmission through the Internet).

Although the present invention has been particularly shown and describedwith reference to exemplary embodiments thereof, it will be understoodby those skilled in the art that various changes in form and details maybe made therein without departing from the spirit and scope of theinvention as defined by the appended claims. The exemplary embodimentsshould be considered in descriptive sense only and not for purposes oflimitation. Therefore, the scope of the invention is defined not by thedetailed description of the invention but by the appended claims, andall differences within the scope will be construed as being included inthe present invention.

1. A method of providing synchronization files to clients to synchronizeserver-side electronic program guide (EPG) information with client-sideEPG information, the method comprising: if synchronization files werecreated according to respective updates of the server-side EPGinformation, updating the synchronization files according to informationwhich is modified after a last synchronization file of thesynchronization files is created; creating a new synchronization fileaccording to the information which is modified after the lastsynchronization file is created; and transferring a firstsynchronization file to one of the clients, the first synchronizationfile being one of the plurality of the synchronization files or the newsynchronization file, wherein the first synchronization file is createdfirst after the client-side EPG information is updated.
 2. The method ofclaim 1, further comprising: writing action type information into anaction type field of an item modified, in an EPG table whenever theserver-side EPG information is updated; and initializing the action typefield after the creating the new synchronization file, wherein, in theupdating the synchronization files, the information which is modified isrecognized with reference to the action type field.
 3. The method ofclaim 2, further comprising, after the creating the new synchronizationfile, deleting data from a server if the data corresponds to a deleteitem in the action type field.
 4. The method of claim 1, wherein theupdating the synchronization files comprises: updating an oldestsynchronization file of the synchronization files to include recent EPGinformation; and updating remaining synchronization files of thesynchronization files other than the oldest synchronization fileaccording to information on the oldest synchronization file.
 5. Themethod of claim 1, wherein, in the creating the new synchronizationfile, the new synchronization file is created such that a file name ofthe new synchronization file comprises information on a file creationdate and information on a file creation time.
 6. The method of claim 1,further comprising: updating a second oldest synchronization file of thesynchronization files at a first time after the creating the newsynchronization file, so that the second oldest file includes recent EPGinformation; and deleting an oldest synchronization file of thesynchronization files from a server.
 7. The method of claim 1, wherein,if there are no synchronization files to be updated, the newsynchronization file which is created includes information on all itemsin a recent EPG table.
 8. A computer-readable medium having embodiedthereon a computer program for executing a method of providingsynchronization files to clients to synchronize server-side electronicprogram guide (EPG) information with client-side EPG information, themethod comprising: if synchronization files were created according torespective updates of the server-side EPG information, updating thesynchronization files according to information which is modified after alast synchronization file of the synchronization files is created;creating a new synchronization file according to the information whichis modified after the last synchronization file is created; andtransferring a first synchronization file to one of the clients, thefirst synchronization file being one of the plurality of thesynchronization files or the new synchronization file, wherein the firstsynchronization file is created first after the client-side EPGinformation is updated.
 9. A server apparatus for providingsynchronization files to clients so as to synchronize server-sideelectronic program guide (EPG) information with client-side EPGinformation, the apparatus comprising: a file storing unit which storessynchronization files created according to the respective updates of theserver-side EPG information; a scheduler which generates an event tocreate a new synchronization file according to items that are modifiedin an EPG table after a last synchronization file of the synchronizationfiles are created; an update information synchronizer which updates thesynchronization files stored in the file storing unit according to theitems that are modified when the event is generated, creates the newsynchronization file based on the items that are modified, and storesthe new synchronization file in the file storing unit; and a filetransfer unit which transfers a first synchronization file to one of theclients, wherein the first synchronization file is created first afterthe client-side EPG information of the one of clients is updated, thefirst synchronization file being one of the synchronization files andthe new synchronization file stored in the file storing unit.
 10. Theapparatus of claim 9, further comprising: an update history setting unitwhich writes action type information into an action type field of theitem that is modified, in the EPG table to be stored in a database whenthe server-side EPG information is updated, and initializes the actiontype field if the update information synchronizer creates the newsynchronization file according to the item that is modified, wherein theupdate information synchronizer recognizes the item that is modifiedwith reference to the action type field.
 11. The apparatus of claim 10,wherein the update history setting unit deletes data from the databaseif the data corresponds to a delete item of the action type field, whenthe update information synchronizer creates the new synchronization filebased on the item that is modified.
 12. The apparatus of claim 9,wherein the update information synchronizer comprises: a firstsynchronizer which updates an oldest synchronization file of thesynchronization files stored in the file storing unit, so that theoldest synchronization file includes recent EPG information; and asecond synchronizer which updates rest of synchronization files otherthan the oldest synchronization file stored in the file storing unitaccording to an update of the oldest synchronization file by the firstsynchronizer.
 13. The apparatus of claim 9, wherein the updateinformation synchronizer is operable to generate a synchronization filename including information on a file creation date and information on afile creation time when the new synchronization file is createdaccording to the items that is modified.
 14. The apparatus of claim 9,further comprising a synchronization file manager which updates a secondoldest synchronization file of the synchronization files stored in thefile storing unit if an event for file management is generated, so thatthe second oldest synchronization file reflects recent EPG information,and then deletes an oldest synchronization file of the synchronizationfiles stored in the file storing unit, wherein the scheduler generatesthe event for file management cyclically at time intervals.
 15. A methodof synchronizing client-side electronic program guide (EPG) informationwith server-side EPG information in a digital broadcasting network, themethod comprising: receiving a list of synchronization files which arecreated according to updates of the server-side EPG information;selecting a synchronization file in the list of the synchronizationfiles, the synchronization files which is created first after a latestupdate time of the client-side EPG information, and receiving thesynchronization file; and updating the client-side EPG information byusing the received synchronization file, wherein the synchronizationfiles in the list reflect recent server-side EPG information.
 16. Themethod of claim 15, wherein each of the synchronization files in thelist has a file name comprising information on a file creation date andinformation on a file creation time.
 17. A computer-readable mediumhaving embodied thereon a computer program for executing a method ofsynchronizing client-side electronic program guide (EPG) informationwith server-side EPG information in a digital broadcasting network, themethod comprising: receiving a list of synchronization files which arecreated according to updates of the server-side EPG information;selecting a synchronization file in the list of the synchronizationfiles, the synchronization files which is created first after a latestupdate time of the client-side EPG information, and receiving thesynchronization file; and updating the client-side EPG information byusing the received synchronization file, wherein the synchronizationfiles in the list reflect recent server-side EPG information.
 18. Aclient apparatus for synchronizing client-side EPG information withserver-side EPG information in a digital broadcasting network, theapparatus comprising: a file determining unit which determines a file tobe received, the file to be received being included in a synchronizationfile list, the file being a synchronization file created first after theclient-side EPG information is updated to a latest version; a filerequesting unit which requests the synchronization file selected in thefile determining unit from a sever in a file request; and an update unitwhich updates the client-side EPG information by using thesynchronization file received in response to the file request, whereinall of the synchronization files in the list reflect recent server-sideEPG information.
 19. The apparatus of claim 18, wherein each of thesynchronization files in the list has a file name comprising informationon a file creation date and information on a file creation time.
 20. Themethod of claim 6, wherein the first time is predetermined.
 21. Theapparatus of claim 14, wherein the time intervals are predetermined.